We have a new Exchange 2010 SP1 installation on Win 2008R2 SP1. We do have a legacy Exchange 2003 server where almost all mailboxes reside, and we'll be moving these to the new Exchange server. I'm not sure if the subject error started before or after this, but the Exchange 2003 users couldn't get to their mailboxes after the Exchange 2010 installation. I ran this command, and the 2003 users started working OK. Set-OwaVirtualDirectory -identity "valorum\owa (Default Web Site)" -Exchange2003URL https://mail.domain.com/exchange What I see now is that under the Default Web Site, Exchange appears as an application and not a virtual directory. I have access to a couple of other Exchange 2010 server, and I've seen how these don't have folder redirection for /owa, /ecp, /EWS, and /Autodiscover, but all of these have redirection configured on the Exchange server that doesn't work - and they are all pointed to /owa. If I attempt to disable this for one, they all disable. I've thought about recreating the owa virtual directories, but I thought that maybe someone might have a better idea. Thanks

Why do you feel that you need to do that?Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

Hi, Here are some suggestion: 1 Confirm whether you have redirection in Default Web Site and remove it. Confirm whether you have redirection in the OWA virtual directory and remove it. Perform an IISRESET 2 Verify whether HTTP and HTTPS binding for IP address 127.0.0.1 is missing from Default Web Site. Add the following bindings to the Default Web Site. Type IP Port HTTP 127.0.0.1 80 HTTPS 127.0.0.1 443 Best Regards!

Because /Exchange is showing up as an application and not a virtual directory.

There is no redirection in the Default Web Site. Both HTTP and HTTPS have bindings to the loopback address. I hadn't tried to browse to the loopback address before, but it returned an error: Server Error in '/' Application. Could not load type 'System.ServiceModel.Activation.HttpModule' from assembly 'System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below. Stack Trace: [TypeLoadException: Could not load type 'System.ServiceModel.Activation.HttpModule' from assembly 'System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.] System.RuntimeTypeHandle.GetTypeByName(String name, Boolean throwOnError, Boolean ignoreCase, Boolean reflectionOnly, StackCrawlMarkHandle stackMark, Boolean loadTypeFromPartialName, ObjectHandleOnStack type) +0 System.RuntimeTypeHandle.GetTypeByName(String name, Boolean throwOnError, Boolean ignoreCase, Boolean reflectionOnly, StackCrawlMark& stackMark, Boolean loadTypeFromPartialName) +314 System.Type.GetType(String typeName, Boolean throwOnError, Boolean ignoreCase) +95 System.Web.Compilation.BuildManager.GetType(String typeName, Boolean throwOnError, Boolean ignoreCase) +124 System.Web.Configuration.ConfigUtil.GetType(String typeName, String propertyName, ConfigurationElement configElement, XmlNode node, Boolean checkAptcaBit, Boolean ignoreCase) +76 [ConfigurationErrorsException: Could not load type 'System.ServiceModel.Activation.HttpModule' from assembly 'System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.] System.Web.Configuration.ConfigUtil.GetType(String typeName, String propertyName, ConfigurationElement configElement, XmlNode node, Boolean checkAptcaBit, Boolean ignoreCase) +11442156 System.Web.Configuration.Common.ModulesEntry.SecureGetType(String typeName, String propertyName, ConfigurationElement configElement) +69 System.Web.Configuration.Common.ModulesEntry..ctor(String name, String typeName, String propertyName, ConfigurationElement configElement) +62 System.Web.HttpApplication.BuildIntegratedModuleCollection(List`1 moduleList) +264 System.Web.HttpApplication.GetModuleCollection(IntPtr appContext) +1372 System.Web.HttpApplication.RegisterEventSubscriptionsWithIIS(IntPtr appContext, HttpContext context, MethodInfo[] handlers) +149 System.Web.HttpApplication.InitSpecial(HttpApplicationState state, MethodInfo[] handlers, IntPtr appContext, HttpContext context) +352 System.Web.HttpApplicationFactory.GetSpecialApplicationInstance(IntPtr appContext, HttpContext context) +407 System.Web.Hosting.PipelineRuntime.InitializeApplication(IntPtr appContext) +375 [HttpException (0x80004005): Could not load type 'System.ServiceModel.Activation.HttpModule' from assembly 'System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.] System.Web.HttpRuntime.FirstRequestInit(HttpContext context) +11612256 System.Web.HttpRuntime.EnsureFirstRequestInit(HttpContext context) +141 System.Web.HttpRuntime.ProcessRequestNotificationPrivate(IIS7WorkerRequest wr, HttpContext context) +4842149 Version Information: Microsoft .NET Framework Version:4.0.30319; ASP.NET Version:4.0.30319.1

I have some more information. When I remove redirection from just about everything related to OWA (I just have to remove redirection from one application or virtual directory and IIS removes it from just about everything else), I can see the calendar and even create contacts, although I still can't delete emails. I have been almost completely successful in setting the parameters alike for both working Exchange servers and the non-working Exchange server. What I'm unable to do is to creating exact settings for owa - for the working Exchange servers, owa redirection box is checked and the destination is empty. On the non-working Exchange server, I can't leave it blank as it says the configuration is invalid. If I set it to anything else, http redirection changes for all the other applications and virtual directories, and I can no longer log in via OWA.

The problem is solved after opening a case with Microsoft. There were two separate issues: 1) Not being able to delete and forward emails was due to a problem with the EWS directory. This was recreated through "Remove-WebServicesVirtualDirectory" and "New-WebServicesVirtualDirectory." 2) We had a separate issue where we couldn't access public folders. I don't recall which one we change, but in the Application Pools of the IIS Manager, either the DefaultAppPool or the MSExchangeOWAAppPool had the .NET framework version set to v4.0. After changing the value to v2.0, this part started working. We now have a fully functional Exchange server